The Wireless Local Area Network (WLAN) ecosystem e.g. Wi-Fi Alliance (WFA) have been developing certifications (e.g. Passpoint™ based on WFA Hot Spot 2.0 specifications) that can automate the mobile device access to WLAN networks using 802.1x port based authentication and hence make the user access experience to WLAN more cellular like. In order to provide security matching that of cellular networks, authentication signalling towards the centralised Authentication, Authorisation and Accounting server (AAA server) in the service provider's core network is required, especially when using cellular network credentials like those in the (U) SIM (Universal Subscriber Identity Module).
However, uncontrolled automatic authentication by smartphones on WLAN access networks can create signalling overload on critical cellular Core network elements, especially the 3GPP AAA server and the subscription databases like Home Location register (HLR). The problem is caused by the 3GPP AAA server receiving too many requests for authentication within a certain time (relative to its dimensioned capacity) and/or the interface between the 3GPP AAA server and a subscription database (HLR) being overloaded with signalling.
This problem has been recognised by the GSM Association (GSMA) and the Wireless Broadband Alliance (WBA) and a task force has been setup to find solutions to this problem. Solutions are required for the following scenarios:                UE (User Equipment) mobility in dense hotspot scenarios e.g. stadiums        Wide scale deployment of community Wi-Fi solutions;        Transport hubs creating sudden surge of authentication when users alight at train stations or airports.        
The following solution categories have been considered to reduce and control signalling load on the cellular operator 3GPP AAA server and subscription databases due to WLAN authentication.
1. Control the Behaviour of UE—Reduce Number of Full Authentication Requests to Core Network.
One basic approach is for the operator to define Access Network Discovery and Selection Function (ANDSF) new operator policies (specified in 3GPP TS 24.312) that:                a) Provide policies about subscription validity to prevent a UE from trying to associate with a WLAN Access Point (AP) when that WLAN network would not be suitable (e.g. because the UE subscription does not allow WLAN access in the given UE location or is not valid for the time of the day).        b) Allow the operator to control, per type of AP (SSID, OUI, Venue Type, etc. . . . ), the frequency of authentication requests (low, medium, high) or maximum number of authentication requests that a UE may use to try to associate with this AP.        c) Allow the operator to define policy for a UE to authenticate/not authenticate to a certain AP type depending on its mobility state. The connection manager may use proprietary solutions to estimate the UE speed and map to the mobility state defined in the operator policy (mobility state definitions in terms of UE speed could be specified). Examples of policies could be:                    for a ‘High’ mobility state UE to not associate to a certain type of AP e.g. ‘shopping mall APs’ but allowed to associate to ‘Transport based’ APs e.g. APs on trains.            for a UE with ‘high’ mobility state to wait for a certain time period to associate on the AP (e.g. prevents UE in car associating to AP at traffic light).                        d) Allow an operator to define policy based on UE knowledge of previously connected AP type and detected AP type e.g. randomly delay access to an AP of type ‘station’ over a time period (defined in the policy) if the previously connected AP type was ‘transport based’ e.g. to spread signalling load and avoid signalling peaks at train stations.        e) Allow operator to define policy that limits or prevents authentication requests from a device where the received signal strength of the target AP is below a certain threshold e.g. to prevent UE authenticating at the edge of an AP and then immediately moving out to a different AP, especially if the UE is ‘ping-ponging’ between the APs.        
A drawback of this solution is that the ANDSF policies are static do not respond to dynamic changes in AAA server load.
2. Control UE Behaviour when Authentication Requests Either Fail or are Rejected.
Define appropriate error codes (and scope and time duration) that are interpreted by the UE to:                a. Stop retrying an access attempt to the same WLAN access during a delay set by the network (e.g. when the rejection corresponds to a temporary network overload), or        b. Stop retrying an access attempt to any AP of the same WLAN access indefinitely when the rejection is due to a permanent error (e.g. no subscription to the service on this WLAN access), and/or        
A drawback of this solution is that it only limits the signalling due to re-authentication.
3. Use Key Caching for Deployments Where a WLAN Controller is Deployed.                a. In its most basic form it involves caching the Pairwise Master Key (PMK) in each AP so that it can be re-used if the UE returns to the same AP. However, it can also be used in a form whereby the UE can pre-authenticate in its current AP in order to prepare new PMKs for visiting neighbouring APs under the same WLAN access controller. This pre-authentication is done locally by the WLAN controller and does not increase load on the AAA.        b. There are also more sophisticated techniques where a single PMK (pairwise master key) or PTK (pairwise transient key) can be used across multiple APs. Examples of these approaches include Cisco's proprietary CCKM technique, and Proactive Key Caching (PKC) (also called Opportunistic Key Caching, OKC) which was introduced in 802.11i. These are more efficient than PMK caching but have the disadvantage that they are not as widely supported on clients.        c. 802.11r is a more efficient form of PKC/OKC which aims to deliver AP transition times on a par with the proprietary CCKM solution.        
These solutions are effective for scenarios where a WLAN controller is present for the PMK caching and surrounding APs which UE can visit can be prepared for them to allow the UE access without authentication. However, these solutions are ineffective for scenarios like community Wi-Fi.
4. Fast Re-Authentication Techniques to Limit Signalling Traffic Sent to Core Network Nodes.
These are enabled by the Authentication Server providing Fast Re-Authentication Identity and other parameters to the Wireless Protected Access (WPA) supplicant instantiated on the end-user device, as part of normal Full Authentication procedure. When the WPA supplicant requires authentication subsequent to a given Full Authentication, it can optionally use a Fast Re-authentication procedure. The signalling load generated by the fast Re-authentication procedure is less than that required for a full authentication.
This solution does not prevent or limit the generation of unnecessary authentication attempts and is only useful if each UE has to perform frequent authentication.
5. Only Authenticate when Traffic Needs to be Passed
The basic approach is for the device operating system to define logic that gauges whether any applications are ready to consume data or are entitled to consume data.
This solution relies on an accurate estimate of the data activity of the UE.
6. Control Behaviour of AAA Server                a. Rate limit number of authentication requests        b. Limit number of authentication requests a AAA server can send to other AAA servers and/or towards an HLR/HSS        
Such an approach does not distinguish between unnecessary authentication requests and authentication requests that are meaningful. Thus, it might end up penalising users who really need to access WLAN at the benefit of users who do not need access at the time but UE is just making automatic and unnecessary authentication.
Accordingly, there is a need for a solution that controls in an effective and simple manner the authentication of WLAN.